1. Technical Field
The present invention relates to a system and method that provides selective authentication when a user is acquiring a role. More particularly, the present invention relates to a system and method that allows various types of authentication, such as entry of user-centric passwords, role-centric passwords, or the like, in order for a user to acquire a particular role.
2. Description of the Related Art
Role-Based Access Control (RBAC) is an evolving technical means for controlling access to computer resources. Access is the ability to do something with a computer resource (e.g., use, change, or view). Access control is the means by which the ability is explicitly enabled or restricted in some way (usually through physical and system-based controls). Computer-based access controls can prescribe not only who or what process may have access to a specific system resource, but also the type of access that is permitted. These controls may be implemented in the computer system or in external devices.
Using RBAC, access decisions are based on the roles that individual users have as part of an organization. Users take on assigned roles. Using a banking example, roles might include teller, loan officer, supervisor, and manager. In traditional RBAC implementations, access rights are grouped by role name, and the use of resources is restricted to individuals authorized to assume the associated role. For example, within a bank the role of supervisor can include functions to perform withdrawal and deposit transactions as well as correct errors noted on customer's bank statements; and the role of teller can be limited to withdrawal and deposit transactions without the ability to correct errors with customer's accounts. The use of roles to control access can be an effective means for developing and enforcing enterprise-specific security policies, and for streamlining the security management process.
Under a traditional RBAC framework, users are granted membership into roles based on their competencies and responsibilities in the organization. The operations that a user is permitted to perform are based on the user's role. User membership into roles can be revoked easily and new memberships established as job assignments dictate. Role associations can be established when new operations are instituted, and old operations can be deleted as organizational functions change and evolve. This simplifies the administration and management of privileges; roles can be updated without updating the privileges for every user on an individual basis.
When a user is associated with a role: the user is given no more privilege than is necessary to perform the job. This concept of least privilege requires identifying the user's job functions, determining the minimum set of privileges required to perform that function, and restricting the user to a domain with those privileges and nothing more. In less precisely controlled systems, this is often difficult or costly to achieve. Someone assigned to a job category may be allowed more privileges than needed because is difficult to tailor access based on various attributes or constraints. Since many of the responsibilities overlap between job categories, maximum privilege for each job category could cause harmful access.
Under RBAC, roles can have overlapping responsibilities and privileges; that is, users belonging to different roles may need to perform common operations. Some general operations may be performed by all employees. In this situation, it would be inefficient and administratively cumbersome to specify repeatedly these general operations for each role that gets created. Role hierarchies can be established to provide for the natural structure of an enterprise. A role hierarchy defines roles that have unique attributes and that may contain other roles; that is, one role may implicitly include the operations that are associated with another role.
Organizations can establish the rules for the association of functions with roles. For example, a bank may decide that the role of teller must be constrained to the functions of withdrawals, deposits, and account balance inquiries, but not to the functions of modifying customer accounts or approving or denying loan requests.
For example, there are differences between the access needs of a teller and an accounting supervisor in a bank. An enterprise defines a teller role as being able to perform a savings deposit function. This requires read and write access to specific fields within a savings file. An enterprise may also define an accounting supervisor role that is allowed to perform customer account correction functions. These operations require read and write access to the same fields of a savings file as the teller. However, the accounting supervisor may not be allowed to initiate deposits or withdrawals but only perform corrections after the fact. Likewise, the teller is not allowed to perform any corrections once the transaction has been completed. The difference between these two roles is the functions that are executed by the different roles and the values that are written to a transaction log file.
While a traditional RBAC framework provides administrators with the capability to regulate who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances, traditional RBAC schemes face certain challenges. First, in many traditional RBAC schemes, a user is granted access to all of their roles all of the time. Using a banking example of this type of RBAC system, when the account supervisor accesses the system (e.g., logs on) the supervisor has access to both teller operations and supervisor operations, even if the supervisor is currently acting in a teller capacity. This RBAC scheme poses security risks. For example, if the supervisor (acting as a teller), leaves his or her station for a brief period of time, another teller that does not have supervisor privileges can use the supervisor's system to perform unauthorized transactions.
Second, in many traditional RBAC schemes, passwords are shared amongst users in order to acquire a role. In this scheme, using the banking example, supervisors would share a “supervisor” password used to access the supervisor role operations and tellers would share a “teller” password used to access the teller role operations. This scheme is challenged by users sharing passwords which is less than secure as sensitive passwords can more easily fall into unauthorized persons' hands (e.g., when an employee is dismissed, he or she still knows the shared passwords that access various operational roles until the password is changed and re-shared amongst the remaining employees). Another challenge of this scheme is that employees need to enter passwords for each role that they acquire. For a manager or other person with authorization to perform several roles, this requires keeping track of a larger number of shared passwords. This results in employee inefficiency in keeping track of numerous shared passwords as well as poses a security risk as employees may resort to writing down the shared passwords on a piece of paper that may fall into the wrong hands.